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@ Webbrowser-basiertes Konferenzsystem 

© Beschrieben wird ein computergestutztes Application- 
Sharing Konferenzsystem, bei dem Konferenzteilnehmer 
gleichzeitig in einem Anwendungsprogramm arbeiten 
konnen. Insbesondere sind die jeweiligen Endsysteme 
uber das Internet oder ein Intranet miteinander gekoppelt. 
Benutzereingaben und die Darstellung des Anwendungs- 
programms auf dem jeweiligen Endsystem werden durch 
ein Sharing-Servermodul sowie ein Sharing-Ciientmodul 
prozessiert. Diese Module werden den jeweiligen Konfe- 
renzteilnehmern beispielsweise als JAVA-Appelets zur 
Verfugung gestellt. Das Konferenzsystem ist insbesonde- 
re Plattform-unabhangig. 
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Beschreibung 

Die Erfindung betrifft coinputergestutzte Video- oder Audiokonferenzsysteme, insbesondere sogenannte erweiterte 
Application-Sharing Systeme, bei denen zwei oder mehrere Gegenstellen direkt in einem Anwendungsprogramm arbei- 
5 ten konnen. 

Unter dem Begriff "Application-Sharing" verbergen sich im allgemeinen unterschiedliche Auffassungen. Im einfach- 
sten Fall wird dem Anwender die Moglichkeit gegeben, ausgewahlte Bildschirminhalte an die jeweilige Gegenstelle zu 
tibertragen. Je nach Konzept wird dabei ein Videofenster benutzt, oder es werden zusatzliche Programmfenster auf der 
Gegenseite geoffnet. Beide Teilnehmer konnen so Daten oder Diagramme besprechen. 

10 Beim sogenannten "erweiterten Application-Sharing" konnen nun beide Gegenstelien direkt in einem Anwendungs- 
programm arbeiten. Das Programm lauft dabei nur auf einem Rechner, stellt aber Bedienungsfunktionen wie Tastaturein- 
gabe oder Maussteuerung auch auf dem bzw. den anderen an der Konferenz beteiligten Rechnern zur Verfugung. Klei- 
nere Datenmengen lassen sich dabei direkt iiber die in Windows-basierten Systemen ("Windows" ist eine eingetragene 
Marke der Microsoft Corp.) bekannten Zwischenablagen austauschen. Dabei werden auf dem Ursprungsrechner die ent- 

15 sprechenden Daten markiert und in die Zwischenablage kopiert. Das Application -Sharing Modul sorgt dann dafiir, da6 
die Daten in die Zwischenablage des Zielrechners ubertragen werden, von wo aus sie beispielsweise iiber den "Einfu- 
gen"-Befehl in fast jedes beliebige Programm ubemommen werden konnen. 

Eine weitere Hilfe fur computerubergreifende Teamarbeit stellt ein Notizblock ("Shared Whiteboard") wie beispiels- 
weise in dem von der Firma Intel entwickelten Application-Sharing Programm "ProShare" ("ProShare" ist eingetragene 

20 Marke der Intel Corp.) dar. Es erlaubt die gemeinsame Bearbcitung eines Schmierzettels mit beliebig zu plazierenden 
Textblocken, Markierungen und einfachen grafischen Skizzen. Dariiber hinaus bietet ProShare die Moglichkeit, Einzel- 
bilder aus dem angezeigten Videofenster einzufrieren und als Bitmap-Datei auf einer Festplatte zu speichern. So laBt sich 
leicht ein PaBfoto der Gesprachspartner oder ein SchnappschuB der vor eine Kamera gehaltenen Dokumente auf die Fest- 
platte bannen. 

25 Der Videokonferenzrechner ist in nahezu alien Fallen ein Windows-Rechner. Andere Betriebssysteme wie OS/2, Unix 
oder Mac (diese Namen sind eingetragene Marken jeweils der Firmen IBM, AT&T und Apple) werden derzeit kaum bis 
gar nicht unterstutzt. Traditionelle Konferenzanwendungen erfordern deshalb, daB jeder Konferenzteilnehmer eine Li- 
zenz der Konferenzanwendung erwirbt, wobei diese Anwendungen oft an eine einzige Betriebssystemplattform gebun- 
den sind. Bisherige Application- Sharing Systeme sind daher als traditionelle Anwendungen konzipiert, deren Einsatz auf 

30 ein oder mehrere Betriebssysteme beschrankt ist, Beispiele solcher Anwendungen sind P2P, Intel ProShare oder Sha- 
red_X ("P2P" und "Shared_X" sind eingetragene Marken der IBM und HP). Die Benutzer einer Konferenzanwendung 
sind daher gezwungen, sich auf ein Produkt zu einigen oder Produkte zu verwenden, die einen gemeinsamen Standard 
benutzen. Konferenzanwendungen, die das gemeinsame Bearbeiten von Dokumenten erlauben, befolgen meist keinen 
gemeinsamen Standard. 

35 Es sind dariiber hinaus bereits Konferenz-Anwendungssysteme bekannt, die ein Sharing von HTTP-Dokumenten un- 
ter Benutzung von konventionellen WWW-(World Wide Web) Servern ermoglichen. Ein solches System ist in dem Ar- 
tikel "A Design and Implementation of Conference Mosaic" der Autoren Euihyun Jung et al. als Conference Proceedings 
der "10th International Conference on Information Networking", POSTECH Information Research Lab, Pohang, South 
Korea, beschrieben. Dieses System weist eine gewohnliche Benutzerschnittstelle, ahnlich dem bekannten "Mosaic" 

40 WWW-Browser, auf. Insbesondere basiert das System sogar auf dem Mosaic-Browser, der fur die Konferenzanwendung 
entsprechend modifiziert wurde. In einem speziellen Arbeitsmodus werden die gemeinsam benutzten (shared) Daten vor 
einer Konferenz auf das jeweilige lokale System jedes Konferenzteilnehmers heruntergeladen, ohne daB eine Verbindung 
zu dem WWW-Server aufgebaut werden muB. Der Anwendungsbereich dieses Konferenzsystems reicht von interaktiven 
online-Spielen und gleichzeitig von mehreren Benutzern bearbeiteten Anwendungsprogrammen bis zum Sharing von In- 

45 ternet Dienstleistungen, wie z. B. der bekannte FTP (File Transfer Protocol) Gopher. 

Ein weiteres Apphcation-Sharing System, unter Verwendung des Internet, ist aus einem Artikel von H. M. Abdel-Wa- 
hab et al. mit dem Titel "XTV: A Framework for Sharing X Window Clients in Remote Synchronous Collaboration", ver- 
offentlicht in IEEE, New York, 1991, Seiten 159-167, bekannt. XTV ist ein verteiltes System, das ein synchrones Sha- 
ring von X Window- Anwendungen in einer Gruppe von entfernt angesiedelten Benutzern ermoglicht, wobei die Benut- 

50 zer mittels Workstations, basierend auf einer X-Plattform, iiber das Internet miteinander in Verbindung stehen. Die 
Hauptkomponenten dieses Systems sind insbesondere in der Weise ausgelegt, daB sie in anderen Konferenzsystemen und 
Anwendungen wieder verwendbar sind. 

Der vorliegenden Erfindung liegt somit die Aufgabe zugrunde, in einem Informations- oder Rechnernetz ein gattungs- 
gemafies Konferenzsystem bereitzustellen, das unabhangig von der zugrundeiiegenden Betriebssystemplattform das ge- 

55 meinsame Benutzen beliebiger Anwendungen ermoglicht. Insbesondere ist dabei die Verwendung eines herkommlichen 
Internet-Browsers auf Seiten der Konferenzteilnehmer avisiert. 

Diese Aufgabe wird bei der vorliegenden Erfindung dadurch gelost, daB eine auf einer ersten Systemeinheit angeord- 
nete erste Funktionseinheit zum Generieren von Ausgabeinformationen einer auf der ersten Systemeinheit ausgefuhrten 
Anwendung und zum Ubermitteln der Ausgabeinformationen an die mindestens zweite Systemeinheit, so wie zum Emp- 

60 fangen und Verarbeiten von Benutzereingaben von der mindestens zweiten Systemeinheit und zum Einspielen der Be- 
nutzereingaben in die Anwendung, und mindestens eine auf der mindestens zweiten Systemeinheit angeordnete zweite 
Funktionseinheit zum Prasentieren der Ausgabeinformationen auf der mindestens zweiten Systemeinheit, und zum 
Ubermitteln der Benutzereingaben an die erste Funktionseinheit vorgesehen sind. Als Systemeinheit kommen samtliche 
digitalen Endsysteme in Betracht, die einen Speicher zum Speichern der erforderlichen Funktionseinheiten sowie Mittel 

65 zur Aufnahme von Benutzereingaben und zur Presentation der zugrundeiiegenden Anwendung aufweisen. Insbesondere 
kommen als Systemeinheit Arbeitsplatzrechner (PCs), Workstations, oder die derzeit viel diskutierten Netzcomputer in 
Betracht. In einer bevorzugten Ausfiihrungsform reprasentieren dabei die Ausgabeinformationen die grafische Benutz- 
eroberflache der jeweiiigen Anwendung. Es wird hervorgehoben, daB die Erfindung eine gemeinsame Bearbeitung von 
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kompletten Anwendungsprogrammen erlaubt, und nicht nur von einzelnen Dokumenten. 

Da das vorgeschlagene Konferenzkonzept lediglich die allgemein verfiigbaren Web-Browser erfordert, ist es aufgrund 
seiner Unabhangigkeit vom jeweiligen tJbertragungsprotokoll auch vollig plattformunabhangig. Zudem sind keinerlei 
Modifikationen an den bestehenden Web-Browsem erforderlich. Die eigentliche Konferenzanwendung kann daher z. B. 
als JAVA-Applet(s) verteilt und durch eine JAVA-Konferenzanwendung auf dem Web-Server koordiniert werden. 5 

In einer vorteilhaften Ausfiihrung der Erfindung kann vorgesehen sein, daB rnindestens eine mit der ersten und der 
mindestens zweiten Systemeinheit verbundene dritte Systemeinheit vorgesehen ist, die rnindestens eine der beiden Funk- 
tionseinheiten zur Ubertragung an mindestens eine der ersten und zweiten Systemeinheiten bereitsteilt, oder daB rninde- 
stens eine mit der ersten und der mindestens zweiten Systemeinheit verbundene dritte Systemeinheit vorgesehen ist, die 
mindestens eine der beiden Funktionseinheiten zur direkten Ausfiihrung bereitstellt. Somit ist es moglich, die fur die 10 
Konferenz erforderlichen Funktionseinheiten erst kurz vor Beginn einer Konferenz auf den Rechner des jeweiligen Kon- 
ferenzteilnehmers zu ubertragen oder aber die Funktionseinheiten auf einer weiteren Systemeinheit direkt auszufuhren. 
Daher sind Anderungen an den bestehenden Endsystemen der Teilnehmer nicht erforderlich. 

Die Erfindung kann zudem sowohl bei uber ein Intranet oder Uber ein Internet gekoppelten Systemeinheiten angewen- 
det werden. 15 

In einer weiteren Ausgestaltung der Erfindung kann vorgesehen sein, daB als tJbertragungsprotokoll zwischen den Sy- 
stemeinheiten ein TCP/IP (Transmission Control Protocol/Internet Protocol)-gesichertes Verbindungsprotokoll vorgese- 
hen ist. Damit wird das erfindungsgemaBe Konferenzsystem plattformunabhangig. 

In einem weiteren Ausfuhrungsbeispiel ist mindestens eine der Funktionseinheiten als "Applet" (Minianwendung) auf 
einer als Web(HTTP-)Server ausgelegten dritten Systemeinheit bereitgestellt, um das Applet von dem Web-Server vor 20 
Konferenzbeginn in eine der Systemeinheiten der Konferenzteilnehmer herunter zu laden. 

Die Applets konnen danach z. B. auf einer Webseite der Systemeinheiten ausgefuhrt werden. Als Entwicklungsumge- 
bung fur die Applets bietet sich wegen seiner Plattformunabhangigkeit insbesondere JAVA an. 

Die Presentation der Benutzeroberflache der jeweiligen Anwehdung kann iiber ein Standard-Grafikformat, wie z. B. 
GIF, erfolgen, denn diese Formate werden von bestehenden Browsern unterstiitzt. 25 

Weiterhin wird die der Erfindung zugrundeliegende Aufgabe gelost durch ein Verfahren, bei dem die Ausgabeinfor- 
mationen einer auf der ersten Systemeinheit aufgefuhrten Anwendung generiert werden, die Ausgabeinformatipnen an 
die mindestens zweite Systemeinheit ubermittelt werden, die Benutzereingaben von der mindestens zweiten Systemein- 
heit empfangen und verarbeitet werden, die Benutzereingaben in die Anwendung eingespielt werden, die Ausgabeinfor- 
mationen auf der mindestens zweiten Systemeinheit prasentiert werden, sowie die Benutzereingaben an die erste Sy- 30 
stemeinheit ubermittelt werden. 

Weitere vorteilhafte Ausgestaltungen der erfindungsgemaBen Einrichtung und dem Verfahren ergeben sich aus den 
Unteranspriichen. 

Auf der Basis der erfindungsgemaBen Architektur lassen sich beliebige Anwendungen plattformubergreifend verted 
len. Eine anwendungsbezogene Standardisierung, wie dies zum Beispiel im Standard J. 120 fiir eine Whiteboard- Anwen- 35 
dung geschieht, ist hier nicht notwendig, da die Konferenzanwendung zentral fur alle Teilnehmer auf einem HTTP-(Hy- 
pertext Transfer Protocol) Server mit der vorgeschlagenen Konferenzerweiterung lauft. Jeder Teilnehmer benutzt einen 
standardgemaBen HTTP-Browser ohne jede Erweiterung. Damit stehen den Benutzem eines Internets/Intranets sofort 
alle bisherigen Anwendungen zur gemeinsamen Benutzung zur Verfugung, ohne daB fiir jeden Teilnehmer eine Benut- 
zungslizenz fur eine Konferenzanwendung, z. B. fur Intel ProShare, erworben werden muB. 40 

In einem bevorzugten Ausfuhrungsbeispiel wird daher die seitens der Erfindung vorgeschlagene Konferenzanwen- 
dung auf einem HTTP-Konferenz-Server implementiert. Vor Beginn einer Konferenz meldet sich jeder Konferenzteil- 
nehmer bei dem Konferenz-Server an. Fiir alle Konferenzteilnehmer konnen Zugangsberechtigungen unter Priifung ihrer 
Internetadressen eingerichtet und zur Verfugung gestellt werden. Fur Intranetanwendungen kann die Konferenzanwen- 
dung in vorteilhafter Weise als JAVA-Klasse angeboten werden. 45 

Im ubrigen ist zur Durchftihrung der Konferenz kein weiteres Anwendungsprogramm (Konferenzanwendung) bei den 
Konferenzteilnehmern erforderlich. Die mittlerweile auf nahezu jedem Person alcomputer (PC) oder jeder Workstation 
eingerichteten Web-Browser stellen die einzige Voraussetzung fur die Implementierung der Erfindung dar. 

Im folgenden Teil wird die Erfindung anhand von Ausfuhrungsbeispielen eingehender beschrieben. Hierbei zeigen 

Fig. 1 den InformationsfluB in einer bei der Erfindung zugrundegelegten Systemumgebung; 50 

Fig. 2a ein erstes Ausfuhrungsbeispiel fiir den Aufbau einer Web- Sharing Konferenz; 

Fig. 2b ein weiteres Ausfuhrungsbeispiel entsprechend Fig. 2a; 

Fig. 3 eine auf JAVA basierende Benutzerschnittstelle; 

Fig. 4 ein in Anlehnung an Fig. 3 weitergebildetes Ausfuhrungsbeispiel der Erfindung. 

In Fig. 1 ist eine typische Systemumgebung, hier basierend auf das Internet, zusammen mit der der vorliegenden Er- 55 
findung zugrundeliegenden Architektur anhand einer Schemazeichnung dargestellt. In dieser exemplarischen System- 
umgebung ist ein HTTP-Server, der als Application-Sharing Server ausgelegt ist, iiber das Internet mit einer Reihe von 
Konferenzteilnehmern, d. h. HTTP-Clients, verbunden. Es ist hier weiter angenommen, daB die gemeinsam von den 
Teilnehmem benutzte Anwendung auf einem der HTTP-Clients gespeichert ist und dort original ausgefuhrt wird. Dieser 
ist ebenfalls Teilnehmer der Konferenz. Die aktuellen Ausgabeinformationen der Anwendung werden nun iiber den 60 
HTTP-Server jeweils an die HTTP-Clients ubermittelt, damit diese ebenfalls mit der Anwendung interaktiv operieren 
konnen. 

Die meisten der existierenden Anwendungsprogramme sind nicht fur die Benutzung in einer computerunterstiitzten 
Konferenz ausgelegt. Die Benutzeroberflachen dieser Programme erscheinen nur auf einem Bildschirm. Um die Benutz- 
eroberflache auf mehreren Rechnern mit jeweils unterschiedlicher Betriebssystem-Plattform darstellen zu konnen, miis- 65 
sen insbesondere die grafischen Ausgaben der Anwendungsprogramme abgefangen und entsprechend an die Konferenz- 
teilnehmer verteilt werden. Als gemeinsames Austauschformat dient bei dem erfindungsgemaBen Konferenzsystem ein 
HTML-(Hypertext Markup Language) Format. Die Ausgaben der zu verteilenden Anwendung an einen der in Fig. 1 dar- 
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gestellten HTTP-Clients werden zunachst in das HTML-Format umgewandelt und an den Application-Sharing Server 
iibergeben. Dieser ServerprozeB kann auf dem gleichen oder einem entfernten Rechner ausgeflihrt werden. 

Die Umwandlung in das HTML-Format geschieht bei nicht-HTML Anwendungen iiber das GIF-Bildformat Bei 
JAVA Anwendungen wird zur Leistungssteigerung des Konferenzsystems die Verteilung iiber die grafischen Ausgabebe- 
5 fehle an die JAVA-Bibliotheken realisiert. 

Bei dem in Fig. 2a dargestellten Ausfiihrungsbeispiel fur den Aufbau einer Web-Sharing-Konferenz ist angenommen, 
daB zwei iiber das Internet verbundene Endsysteme (Clients) miteinander mittels eines ebenfalls an das Internet angekop- 
pelten Servers kommunizieren. Es wird an dieser Stelle allerdings hervorgehoben, daB die Erfindung bereits in einem 
Netzwerk anwendbar ist, in dem nur ein Client mit einem Server in Verbindung steht, und in denen ein Application-Sha- 

10 ring auch ohne eine zugrundeliegende Konferenz stattfindet. Beispielsweise kann daran gedacht sein, daB neueste Soft- 
wareprodukte zum Austesten von einem Server heruntergeladen werden, wobei die Originalversion weiterhin auf dem 
Server verbleibt und auch dort ausgefuhrt werden kann. 

Bei dem in Fig. 2a gezeigten Netzwerk sind sowohl auf den beiden Endsystemen als auch dem Server Windows-ba- 
sierte Betriebssysteme installiert. Das betreffende Anwendungsprogramm, hier das Zeichenprogramm "Corel Draw" der 

15 Firma Corel ("Corel Draw" ist eingetragene Marke der Firma Corel) ist lediglich auf dem Server installiert. Die erforder- 
liche Betriebssoftware zur Unterstiitzung der Sharing-Konferenz stellt zum einen ein sogenanntes Sharing-Server Modul 
auf dem jeweiligen Server, zum anderen ein sogenanntes Sharing-Client Modul auf den jeweiligen Endgeraten (Clients) 
bereit. Die genannten Programmodule werden in vorteilhafter Weise in der plattformunabhangigen Entwicklungssprache 
JAVA implementiert. Diese Module werden nachfolgend noch eingehender beschrieben. 

20 ' 

Sharing-Servermodul 

Das Sharing-Servermodul hat insbesondere die Aufgabe, die grafischen Ausgaben der zu verteilenden Anwendung zu 
erfassen und die Benutzereingabe aller Konferenzteilnehmer zu serialisieren und der Anwendung so zu iibergeben, als 
25 seien die Eingaben an der lokalen Arbeitsstation erfolgt. Die folgenden Schritte erlautem den Ablauf einer Konferenz: 

1. Laden des Servermoduls 

' Das Servermodul wird dem Konferenzteilnehmer in Form eines JAVA- Applets zur Verfugung gestellt. Das JAVA- 
Applet bietet dem Benutzer Funktionen an, mit deren Hilfe er eine beliebige Anwendung zur \ferteilung auswahlen 
30 kann. 

2. Erfassen der grafischen Ausgabedaten 

Am Konferenzbeginn erhalt jeder Teilnehmer eine komplette Ausgabe der Anwendung in Form einer komprimier- 
ten Bitmap, z. B. im GIF-Format. Ab diesem Zeitpunkt werden nur die Anderungen, z. B. Textbereiche erfaBt und 
verteilt. 

35 3. Behandlung der Benutzereingaben 

Das Servermodul erhalt die Benutzereingabe direkt von den beteiligten Clientmodulen. Diese Eingaben werden zu- 
nachst auf Gultigkeit uberpriift, d. h. ob das entsprechende Clientmodul berechtigt war, Benutzereingaben anzuneh- 
men. Die Eingabedaten werden iiber die System- Warteschlange des jeweiligen Fenstersystems der Anwendung zur 

, Verfugung gestellt. Da im allgemeinen auch die lokalen Benutzereingaben iiber diese Warteschlange abgearbeitet 

40 werden, ist fiir die Anwendung das Einspielen der Benutzereingaben transparent. 



S haring-Clientmodul 

45 Das Sharing-Clientmodul hat die Aufgabe, die vom Servermodul erhaltenen grafischen Daten in einem Webbrowser 
oder einem separaten Fenster darzustellen. Alle Benutzereingaben, die im Anwendungsbereich des Webbrowsers statt- 
finden werden im Gegenzug dem Servermodul iibergeben. Die folgenden Schritte erlautern den Ablauf einer Konferenz: 

1. Laden des Clientmoduls 

50 Das Clientmodul wird dem Konferenzteilnehmer in Form eines JAVA-Applets zur Verfugung gestellt. Das JAVA- 
Applet bietet dem Benutzer Funktionen an, mit deren Hilfe er das Eingaberecht zu einer verteilten Anwendung er- 
langen kann. ' 

2. Darstellen der grafischen Ausgabedaten 

Bei Konferenzbeginn stellt das Clientmodul die verteilte Anwendung im Webbrowser als Grafik dar. Ab diesem 
55 Zeitpunkt werden nur noch die Anderungen an dieser Grafik, z. B. das Zeichnen eines Kreises, nachvollzogen. 

3. Erfassen der Benutzereingaben 

Das Clientmodul erhalt samtliche Benutzereingaben, die auf der Anwendung im Webbrowser erfolgen. Diese Be- 
nutzereingaben werden an das Servermodul* weitergeleitet, falls der Benutzer zuvor das Eingaberecht angefordert 
und erhalten hatte. . 

60 

Zu Beginn einer Konferenz wahlen sich die Teilnehmer der Konferenz z. B. an einem Application- Sharing HTTP-Ser- 
ver ein. Dieser Vorgang kann durch ein vor der Konferenz an die jeweiligen Teilnehmer verteiltes PaBwort geschiitzt 
werden. Danach erhalt jeder Teilnehmer den aktuellen Zustand der Konferenz als eine HTML-Seite angezeigt Diese 
HTML-Seite stellt die Benutzeroberfiache der zu verteilenden Anwendung dar. Jeder Teilnehmer hat nun die Moglich- 
65 keit, selbst dieses Programm zu bedienen. Die Benutzereingaben der Teilnehmer werden von dem als JAVA-Applet be- 
reitgestellten Sharing-Client Modul aufgenommen und von diesem an das Sharing-Server Modul weitergeleitet. Dort 
werden die Eingaben mittels des Sharing-Server Moduls dem jeweiligen Anwendungsprogramm als Benutzereingaben 
eingespielt. Die entsprechenden Anderungen an der Benutzeroberfiache werden wiederum an alle Konferenzteilnehmer 
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verteilt. 

Bei dem in Fig. 2b dargestellten Ausfuhrungsbeispiel ist, im Gegensatz zu der Ausfuhrungsform gemaB Fig. 2a, das 
jeweilige Anwendungsprogramm nicht auf dem Server, sondern auf einem der Clients angeordnet. Dementsprechend ist 
auch das notwendige Sharing-Server Modul auf diesem Client installiert. Dieser Client verfugt zudem iiber ein HTTP- 
Server-Interface. 5 

In einem weiteren Ausfuhrungsbeispiel der Erfindung steht den Benutzern eine Reihe von Grafikoperationen zur \er- 
fugung, die u. a. das Annotieren auf der verteilten Anwendung erlauben. Diese Funktionen konnen in vorteilhafter Weise 
ebenfalls als JAVA-Klassen auf dem jeweiligen Client-Rechner ausgefuhrt werden. Zur Verdeutlichung wird angenom- 
men, daB in einer Architektur entsprechend Fig. 2a einer der Teilnehmer die Annotation "Dreieckzeichnen" ausfuhrt Das 
entsprechende JAVA- Applet sendet die Informationen iiber das gezeichnete Dreieck, z. B. Koordinaten, Farben oder 10 
Rand, als Ruckmeldung an den Konferenz-HTTP-Server. Dieser verteilt die Informationen dann an alle Clients, die die 
Operation ebenfalls durch das gleiche JAVA-Applet ausfiihren lassen. 

Es wird hervorgehoben, daB erst durch die neuen Fahigkeiten, die JAVA-Klassen in Internet- bzw. Intranet-Anwen- 
dungen zur Verfugung stellen, eine interaktive browserbasierte Konferenzanwendung moglich wird. Die auf den Client- 
Maschinen ausgefuhrten JAVA-Applets sind in der Lage, auf Ereignisse des Konferenz HTTP-Servers zu reagieren. Ein 15 
Benutzer der Konferenzanwendung muB nicht aktiv das Erneuem der jeweiligen HTML-Seite veranlassen. Diese Funk- 
tionalitat der JAVA-Klassen erlaubt auch das Entwickeln von Diensten zur Synchronisation der Benutzereingaben. 

Die Synchronisation der Benutzereingaben kann auf unterschiedliche Art erfolgen. Meist wird das Benutzerrecht zur 
Eingabe mittels eines Eingabe-Tokens geregelt. Der Besitzer eines Tokens entscheidet, an wen er das Eingaberecht wei- 
tergibt Jeder Teilnehmer muB zuvor durch eine Funktion an der Benutzerschnittstelle das Eingaberecht anfordern. 20 

Wie bereits beschrieben, ist es besonders vorteilhaft, die fur die Konferenz erforderlichen Steuermodule in der Ent- 
wicklungssprache JAVA zu programmieren. In einer anderen Ausfuhrungsform der Erfindung wird dieses Konzept da- 
hingehend erweitert, daB auch die zugrundeliegenden Anwendungsprogramme in JAVA programmiert sind. Im folgen- 
den Teil wird daher ein Verfahren beschrieben, um das Verteilen von beliebigen JAVA-Anwendungen zu realisieren. 

Das Verfahren ersetzt die in JAVA standardmaBig enthaltene Komponente zur Darstellung und Behandlung von Ele- 25 
menten der Benutzerschnittstelle durch eine neue Komponente. Dblicherweise befindet sich die Implementierung der fur 
das JAVA-Laufzeitsystem notwendigen Klassen in einer Datei nam ens "Classes .Zip". Dies trifft fur alle Plattformen zu, 
fur die es eine JAVA-Unterstutzung gibt. 

In Fig. 3 ist nun dargestellt, wie eine in JAVA generierte Benutzerschnittstelle durch JAVA-Klassen definiert ist, die in 
den genannten Zip-Dateien abgelegt sind. Diese Datei liegt fur jeden Client vor, wobei die Schnittstelle zu den Klassen 30 
fur alle Plattformen identisch ist. Demgegeniiber stellt sich jedoch die Implementierung der Klassen auf den verschiede- 
nen Plattformen unterschiedlich dar, z. B. werden zur Darstellung. eines Schaltknopfes ("Button") in JAVA-Programmen 
Objekte der Klasse "Button class" erzeugt. Die Implementierung dieser Klasse ist auf jeder Plattform unterschiedlich und 
Bestandteil des jeweiligen JAVA-Laufzeitsystems. Zur Darstellung eines Buttons werden die auf der jeweiligen Platt- 
form vorhandenen originaren Graft kmechanismen ausgenutzt. 35 

Die Architektur des JAVA-Laufzeitsystems ist bis auf die Schnittstellen, die in der genannten Zip-Datei enthalten sind, 
durchgehend identisch. Erst innerhalb dieser Datei befinden sich die plattformabhangigen Implementierungen. Diese 
Tatsache wird bei der vorliegenden Erfindung dadurch ausgenutzt, daB die Implementierung der dem jeweiligen Benut- 
zer zugeordneten Klassen ersetzt wird durch eine Verteilkomponente. Diese Verteilkomponente sorgt fiir den Austausch 
der zur Verteilung der Anwendung notwendigen Daten. Um die Aufgabe der Darstellung und Behandlung von Elemen- 40 
ten der Benutzerschnittstelle erfiillen zu konnen, wird die bestehende Implementierung in die Verteilkomponente einge- 
bettet und von dieser mitbenutzt. 

Dies wird nun anhand von Fig. 4 verdeutlicht. Der ProzeB der Ersetzung von Teilen des bestehenden Programmcodes 
in der genannten Zip-Datei durch einen neuen Teil ist auf alien Systemen ubereinstimmend, da das Dateiformat und das 
Format der Anweisungen innerhalb der Datei standardisiert sind. In Fig. 4 ist dies am Beispiel der Ersetzung des Pro- 45 
grammcodes fur die Behandlung von einfachen Schaltflachen (Buttons) dargestellt. 

Als weiteres Beispiel wird nun anhand eines Pseudo-Codes die Verteilung der Methode zum Setzen der Beschriftung 
eines Buttons beschrieben: 

public class Button { 50 



public void set Label (string text) 

// oldButton ist ein Objekt der urspriinglichen Button- 55 
//Klasse. 

oldButton.set Label (text), 
// ruf t den urspriinglichen 
// Code zum Setzen der Beschriftung auf; 

// die angeschlossenen Clients uber die Anderung der 60 

// Beschriftung informieren, 

verteile Aufruf ("Button.set Text", text oldButton) 

} 

Das beschriebene Verfahren erfullt somit hochste Anspriiche an die Verarbeitungsgeschwindigkeit, da keine Bilddaten 65 
iiber das Netzwerk ausgetauscht werden mussen, sondern nur Informationen wie z. B. "Button" wurde gedriickt oder 
"Button" wird an Position (XY) erzeugt. Auf der jeweiligen Client-Maschine werden diese Befehle wieder in Aufrufe an 
die entsprechenden Klassen fur Schaltflachen in der genannten Datei "Classes.Zip" umgewandelt. 
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Patentanspriiche 

1. Einrichtung zum gemeinsamen Bearbeiten eirier Anwendung auf einer ersten digitalen Systemeinheit und auf 
mindestens einer mit der ersten Systemeinheit verbundenen zweiten digitalen Systemeinheit, gekennzeichnet 

5 durch 

eine auf der ersten Systemeinheit angeordnete erste Funktionseinheit zum Generieren von Ausgabeinformationen 
einer auf der ersten Systemeinheit ausgefuhrten Anwendung und zum tibermitteln der Ausgabeinformationen an 
die mindestens zweite Systemeinheit, sowie zum Empfangen und Verarbeiten von Benutzereingaben von der min- 
destens zweiten Systemeinheit und zum Einspielen der Benutzereingaben in die Anwendung; 
io mindestens eine auf der mindestens zweiten Systemeinheit angeordnete zweite Funktionseinheit zum Prasentieren 

der Ausgabeinformationen auf der mindestens zweiten Systemeinheit, und zum "Obermitteln der Benutzereingaben 
an die erste Funktionseinheit. 

2. Einrichtung nach Anspruch 1, dadurch gekennzeichnet, daB mindestens eine mit der ersten und der mindestens 
zweiten Systemeinheit verbundene dritte Systemeinheit vorgesehen ist, die mindestens eine der Funktionseinheiten 

15 zur Obertragung an mindestens eine der ersten und zweiten Systemeinheiten bereitstellL 

3. Einrichtung nach Anspruch 1, dadurch gekennzeichnet, daB mindestens eine mit der ersten und der mindestens . 
zweiten Systemeinheit verbundene dritte Systemeinheit vorgesehen ist, die mindestens eine der Funktionseinheiten 
zur direkten Ausfuhrung bereitstellt. 

4. Einrichtung nach einem der vorstehenden Anspruche, dadurch gekennzeichnet, daB die Systemeinheiten iiber 
20 ein Intranet oder Internet miteinander verbunden sind. 

5. Einrichtung nach Anspruch 4, dadurch gekennzeichnet, daB als Obertragungsprotokoll zwischen den Systemein- 
heiten ein TCP/EP-Protokoll vorgesehen ist. 

6. Einrichtung nach einem der Anspruche 2, 4 oder 5, dadurch gekennzeichnet, daB mindestens eine der Funktions- 
einheiten als Applet auf einer als Web-(HTTP-) Server ausgelegten dritten Systemeinheit bereitgestellt ist, urn das 

25 Applet von dem Web-Server in eine der Systemeinheiten herunter zu laden. 

7. Einrichtung nach Anspruch 6, dadurch gekennzeichnet, daB das Applet auf einer Webseite mindestens einer der " 
ersten oder zweiten Systemeinheiten ausgefuhrt wird. 

8. Einrichtung nach einem der Anspruche 2 oder 4 bis 7, dadurch gekennzeichnet, daB mindestens eine der Funk- 
tionseinheiten als JAVA Applet ausgelegt ist. 

30 9. Einrichtung nach einem der vorstehenden Anspruche, dadurch gekennzeichnet, daB die Ausgabeinformationen 

die grafische Benutzeroberflache der Anwendung reprasentieren. 

10. Einrichtung nach Anspruch 9, dadurch gekennzeichnet, daB die Benutzeroberflache im Bitmap- oder GIF-For- 
mat reprasentiert ist. 

11. Einrichtung nach einem der Anspruche 2 oder 4 bis 10, gekennzeichnet durch eine Presentation der Ausgabein- 
35 formationen mittels eines bei mindestens einer der Systemeinheiten vorliegenden Web-Browsers. . 

12. Einrichtung nach einem der Anspruche 2 oder 4 bis 11, gekennzeichnet durch Mittel zum Anmelden einer ge- 
meinsamen Bearbeitung einer Anwendung bei der dritten Systemeinheit. 

13. Verfahren zum gemeinsamen Bearbeiten einer Anwendung auf einer ersten digitalen Systemeinheit und auf 
mindestens einer mit der ersten Systemeinheit verbundenen zweiten digitalen Systemeinheit, dadurch gekennzeich- 

40 . net, daB 

Ausgabeinformationen einer auf der ersten Systemeinheit ausgefuhrten Anwendung generiert werden, 
die Ausgabeinformationen an die mindestens zweite Systemeinheit ubermittelt werden, 
Benutzereingaben von der mindestens zweiten Systemeinheit empfangen und verarbeitet werden, 
die Benutzereingaben in die Anwendung eingespielt werden, 
45 die Ausgabeinformationen auf der mindestens zweiten Systemeinheit prasentiert werden, und 

die Benutzereingaben an die erste Systemeinheit ubermittelt werden. 

14. Verfahren nach Anspruch 13, dadurch gekennzeichnet, daB die Verarbeitung der Ausgabeinformationen und 
der Benutzereingaben mittels mindestens einer auf einer der Systemeinheiten vorliegenden Funktionseinheit er- 
folgt, wobei mindestens eine der Funktionseinheiten von einer mit der ersten und der mindestens zweiten System- 

50 einheit verbundene dritte Systemeinheit bereitgestellt und an mindestens eine der ersten und zweiten Systemeinhei- 

ten ubertragen wird. 

15. Verfahren nach Anspruch 13, dadurch gekennzeichnet, daB die Verarbeitung der Ausgabeinformationen und 
der Benutzereingaben mittels mindestens einer auf einer der Systemeinheiten vorliegenden Funktionseinheit er- 
folgt, wobei mindestens eine der Funktionseinheiten zur direkten Ausfuhrung auf einer mit der ersten und der min- 

55 destens zweiten Systemeinheit verbundene dritte Systemeinheit bereitstellt wird. 

16. Verfahren nach einem der Anspruche 13 bis 15, dadurch gekennzeichnet, daB die Systemeinheiten uber ein Int- 
ranet oder Internet miteinander verbunden werden. 

17. Verfahren nach Anspruch 16, dadurch gekennzeichnet, daB Informationen zwischen den Systemeinheiten mit- 
tels eines TCP/EP-Protokolls ubertragen werden. 

60 18. Verfahren . nach Anspruch 15 oder 16, dadurch gekennzeichnet, daB mindestens eine der Funktionseinheiten als 

Applet auf einer als Web-(HTTP-)Server ausgelegten dritten Systemeinheit bereitgestellt wird, urn das Applet von 
dem Web-Server in eine der Systemeinheiten herunter zu laden. 

19. Verfahren nach Anspruch 18, dadurch gekennzeichnet, daB das Applet auf einer Webseite mindestens einer der 
ersten oder zweiten Systemeinheiten ausgefuhrt wird. 
65 20. Verfahren nach einem der Anspruche 15 bis 19, dadurch gekennzeichnet, daB mindestens eine der Funktions- 

einheiten als JAVA Applet ausgelegt wird. 

21. Verfahren nach einem der vorstehenden Anspruche, dadurch gekennzeichnet, daB die Ausgabeinformationen 
als grafische Benutzeroberflache der Anwendung reprasentiert werden. 
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22. Verfahren nach Anspruch 21, dadurch gekennzeichnet, daB die Benutzeroberflache im Bitmap- oder GIF-For- 
mat reprasenuert wird. 

23. Verfahren nach einem der Anspruche 13 oder 15 bis 22, dadurch gekennzeichnet, daB die Ausgabeinformatio- 
nen mittels eines bei mindestens einer der Systemeinheiten vorliegenden Web-Browsers prasentiert werden. 

24. Verfahren nach einem der Anspruche 13 oder 15 bis 23, dadurch gekennzeichnet, daB eine gemeinsame Bear- 
beitung einer Anwendung bei der dritten Systemeinheit vorab angemeldet wird. 
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